home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / iesg / iesg.92-02-20 < prev    next >
Text File  |  1993-02-04  |  18KB  |  490 lines
  1.                      IETF STEERING GROUP (IESG)
  2.  
  3.                   REPORT FROM THE TELECONFERENCE
  4.  
  5.                        February 20th, 1992
  6.  
  7.          Reported by:
  8.          Greg Vaudreuil, IESG Secretary
  9.  
  10. This report contains
  11.  
  12.         - Meeting Agenda
  13.         - Meeting Attendees
  14.         - Meeting Notes
  15.  
  16. Please contact the IESG Secretary, Greg Vaudreuil, for more information.
  17.  
  18. ATTENDEES
  19. ---------
  20.  
  21.     Almquist, Philip / Consultant
  22.     Borman, David / Cray Research
  23.     Chiappa, Noel 
  24.     Crocker, Dave / TBO
  25.     Coya, Steve / CNRI
  26.     Davin, Chuck / MIT
  27.     Estrada, Susan / CERFnet
  28.     Gross, Philip / ANS
  29.     Hobby, Russ / UC-DAVIS
  30.     Reynolds, Joyce / ISI
  31.     Piscitello, Dave/ Bellcore
  32.     Stockman, Bernard / SUNET/NORDUnet
  33.     Vaudreuil, Greg / CNRI
  34.  
  35. Regrets
  36.     Huizer, Erik / SURFnet
  37.     Hinden, Robert / BBN
  38.     Crocker, Steve / TIS
  39.  
  40.  
  41. AGENDA
  42. -------
  43.  
  44. 1.0 Administrivia
  45.  
  46.  1.1 Bash the Agenda 
  47.  1.2 Approval of the Minutes
  48.    1.1.1 December 5th, 1991
  49.    1.1.2 December 12th, 1991
  50.    1.1.3 January 2nd, 1992
  51.    1.1.4 January 23rd, 1992
  52.    1.1.5 February 6th, 1992
  53.  1.3 Next Meeting
  54.  
  55. 2.0 Review of Action Items 
  56.  
  57. 3.0 Protocol Actions 
  58.  
  59.  3.1 SMDS to Draft Standard 
  60.      <RFC 1209>
  61.  3.2 822 Message Header Extensions
  62.      <draft-ietf-822ext-msghead>
  63.  3.3 Frame Relay MIB 
  64.      <draft-ietf-iplpdn-frmib>
  65.  3.4 X.400 88=>84 Downgrading
  66.      <draft-ietf-kille-88to84downgrade>
  67.  3.5 Mapping between X.400(1988) / ISO 10021 and RFC 822
  68.      <draft-ietf-kille-x_400mapping>
  69.  3.6 IP Type of Service
  70.      <draft-almquist-tos-02>
  71.  
  72. 4.0 RFC Editor Actions
  73.  
  74.  4.1 Hybrid NETBIOS End-Nodes
  75.  4.2 DCNL to Experimental 
  76.  
  77. 5.0 Technical Management Issues
  78.  
  79.  5.1 Interoperability testing at IETF meetings.
  80.  5.2 RFC 931 User Authentication Protocol
  81.  5.3 Report from the ROAD Group 
  82.  5.4 IANA and the Class "B" allocation strategy
  83.  5.5 Internet Draft Format Requirements "Deplorable Documents" (PG)
  84.  5.6 Email Host Requirements
  85.  5.7 Working Group Early Warning System 
  86.  5.8 Report of the Ad Hoc meeting on DNS Security 
  87.  5.9 IP over FDDI to Draft 
  88.  5.10 Network Database
  89.  
  90. 6.0 IESG Technical Evolution document.
  91.  
  92. 7.0 Working Group Actions
  93.  
  94.  7.1 Audio/Video Teleconferencing (avt)
  95.  7.2 SNMP over Multi-Protocol Internet (mpsnmp)
  96.  
  97.  
  98. MINUTES
  99. --------
  100.  
  101. 1) Administrivia
  102.  
  103. 1.2 Approval of the Minutes
  104.  
  105.    The minutes of the December 5th, 1991, December 12th, 1991, January
  106.    2nd, 1992, and January 23rd, 1992 meetings were approved. Approval
  107.    of the Minutes of the February 6th teleconference was deferred until
  108.    the next meeting.
  109.  
  110. ACTION: Vaudreuil -- Post the minutes for the December 5th, 1991,
  111. December 12th, 1991, January 2nd, 1992, January 23rd, 1992, and
  112. February 6th, 1992 IESG teleconferences.
  113.  
  114.    The IESG discussed the manner in which action items should be
  115.    recorded in the IESG Minutes.  The assignment and conclusion of
  116.    action items will be recorded in the minutes, but review of action
  117.    items in progress will not be reported.
  118.  
  119. 1.3 Next Meeting
  120.  
  121.    The IESG scheduled a teleconference from 12:00 to 2PM EST Thursday
  122.    March 5th.
  123.  
  124. 2) Action Items
  125.  
  126.    The action items were reviewed by email prior to the meeting. A
  127.    summary of the action items concluded is enclosed as appendix A.
  128.  
  129.  
  130. 3) Protocol Actions
  131.  
  132. 3.1 SMDS to Draft Standard (Noel Chiappa)
  133.     <RFC 1209>
  134.  
  135.    Dave Piscitello related current operational experience of RFC 1209
  136.    IP over SMDS service.  Documentation of SMDS use is available, and
  137.    George Clapp is working on documenting RFC 1209 usage over SMDS.
  138.    This documentation does not need to be presented to the IESG in a
  139.    formal letter.  To make the gathering of information easier, the
  140.    IESG agreed that specific customers and sites do not need to be
  141.    disclosed.  The general question of verifying the accuracy of the
  142.    information was not discussed.
  143.  
  144.    Based on Piscitello's observations, the IESG approved RFC1209 for
  145.    Draft Standard.  The IESG still expects a report by email from
  146.    George Clapp before sending the recommendation to the IAB.
  147.  
  148. ACTION: Vaudreuil -- Craft a message to the IAB recommending RFC 1209
  149. be elevated to Draft Standard Status.  Send the message after the IESG
  150. receives a report on operational experience from George Clapp.
  151.  
  152. 3.2 822 Message Header Extensions
  153.     <draft-ietf-822ext-msghead>
  154.  
  155.    Two issues in the Message Header Extensions document were raised and
  156.    discussed.  There is a small difference in the "Q" encoding of the
  157.    Message Headers and the "Quoted Printable" encoding in MIME.
  158.    Because these two documents are expected to be implemented in the
  159.    same software, there was a feeling that it would be better to use
  160.    the same encoding.  The encodings differ in their treatment of the
  161.    space character, a special character in RFC 822 headers.  The
  162.    Working Group chair responded that the differences in the encodings
  163.    were necessary to achieve the intended effect of having the most
  164.    "reader friendly" representation possible.  The underscore character
  165.    is used represent a space in the header, and a space is left as
  166.    itself in the body.  The IESG was satisfied with this explanation.
  167.  
  168.    The second issue discussed concerned the operational implications of
  169.    changing the header specifications.  It was pointed out the changing
  170.    the interpretation of the comment and quoted-string in the header
  171.    will generally result in a change to the header parsing algorithms
  172.    in user agents.  Because of the complexity of these parsers, and the
  173.    traditionally bad conformance to RFC 822, there was a question about
  174.    whether this change to allow multi-character sets in the headers was
  175.    worth the potential harm to the mail reading infrastructure.  This
  176.    protocol may prompt modifications to software that performs
  177.    addressing parsing, including that done by mail relays, and may
  178.    affect their operation.
  179.  
  180.    The IESG agreed that the risks of this change were acceptable to
  181.    satisfy the needs for multi-lingual users of RFC 822 mail. The
  182.    Message Headers document is one of two documents defining the new
  183.    multi-media/ multi-lingual standards for RFC 822 email.  No action
  184.    is necessary until MIME is approved.
  185.  
  186. 3.3 Frame Relay MIB (Chuck Davin)              LAST CALL: 2/11/92
  187.     <draft-ietf-iplpdn-frmib>
  188.  
  189.    The Frame Relay MIB Last Call was issued.  In response to the last
  190.    call, comments were sent, and a new version of the document was
  191.    published as an Internet Draft.  Recognizing that updates to
  192.    documents that occur very late in the process could be at odds with
  193.    their forward progress in an open way (or at best very confusing to
  194.    the community), the IESG concluded that greater care is warranted in
  195.    handling late-stage documents.
  196.  
  197. POSITION: After a Last Call is issued, no further versions of the
  198. Internet Draft should be posted unless the Area Director specifically
  199. requests such a posting.
  200.  
  201. ACTION: Vaudreuil -- Send a message to the IETF updating the last call
  202. to reflect the current document.
  203.  
  204. 3.5 Mapping between X.400(1988) / ISO 10021 and RFC 822
  205.     <draft-ietf-kille-x_400mapping>
  206.  
  207.    The IESG discussed the current situation with this document.  This
  208.    document has caused the IAB and IESG to clarify and revisit the
  209.    requirements for a standards track protocol not originating in the
  210.    IETF.  This specific document has followed the understood practice,
  211.    and was reviewed at an IETF plenary meeting at a one-shot BOF.
  212.  
  213. ACTION: Gross: Bring this up to the IAB and seek clarification of the
  214. specific procedural objections.  If resolution is not possible,
  215. schedule a meeting at the IETF of the relevant IAB, IESG, and Working
  216. Group members to achieve resolution.
  217.  
  218. 3.6 IP Type of Service
  219.  
  220.   The IP Type of service document was sent to the IAB.  Discussion
  221.   subsequently ensued on the IETF mailing list. The IESG discussed and
  222.   affirmed the decision to recommend TOS for Proposed Standard Status.
  223.  
  224. ACTION: Almquist -- Send a note to the IAB, and or the IETF,
  225. acknowledging the discussion and affirming the IESG position that the
  226. TOS document should be advanced per the IESG recommendation.
  227.  
  228. ACTION: Gross -- Add TOS to the IAB agenda and relay to the IAB the
  229. sense of the IESG in regards to TOS.
  230.  
  231. 4) RFC Editor Actions
  232.  
  233. 4.1 Hybrid NETBIOS End-Nodes
  234.  
  235.    Dave Borman reviewed the NETBIOS document.  The document intends to
  236.    define a new standard end-node beyond the three defined in RFC 1002.
  237.    The extensions outlined in general seems reasonable, however, the
  238.    intent of the author is not clear.  If this is to be an experimental
  239.    document, publication is reasonable.  If this is intended to be a
  240.    Standard, the author needs to bring the document into the IETF.
  241.  
  242. ACTION: Vaudreuil --  Contact the author of the NETBIOS End-Nodes
  243. document, and find out if it is intended to be an experiment or
  244. standards track.
  245.  
  246. 4.2 DCNL to Experimental
  247.  
  248.    The RFC Editor forwarded the IESG the Dynamic Creation of Network
  249.    Links document for review.
  250.  
  251.    This document is an independent submission to the RFC editor, even
  252.    though it was reviewed at an IETF BOF.  There are no plans to submit
  253.    this document to the standards track at this time.  If experiments
  254.    are encouraging, this may serve as a starting place for standards
  255.    track work.
  256.  
  257. ACTION: Vaudreuil -- Notify Jon Postel that the IESG has no objection
  258. to the publication of the DCNL document as an Experimental RFC.
  259.  
  260. 5) Technical Management Issues
  261.  
  262. 5.1 Interoperability testing at IETF meetings.
  263.  
  264.    The IETF Secretariat has received requests to support
  265.    interoperability testing and functional demonstrations at IETF
  266.    meetings. While the IESG believes that non-partisan interoperability
  267.    testing represents one of the biggest strengths of the Internet
  268.    Community, it believes that the IETF itself should not be the
  269.    explicit sponsor of such events. To do so probably goes beyond the
  270.    original charter of the IETF. Plus, there is the legitimate concern
  271.    that the IETF Secretariat does not have the resources to support
  272.    this type of additional activity.
  273.  
  274. POSITION:  Demonstrations and interoperability testing cannot be
  275. considered part of the IETF meeting itself, although there is no reason
  276. why the results cannot be shared with the relevent WGs, if
  277. approporiate. The IETF Secretariat does not have the resources to
  278. assist in planning such activites and therefore any such demos or tests
  279. have to organized and implemented by those performing the activity or
  280. function.
  281.  
  282. 5.2 RFC 931 User Authentication Protocol
  283.  
  284.    Because Steve Crocker was unable to attend, this topic was skipped.
  285.  
  286. 5.3 Report from the ROAD Group
  287.  
  288.    At its last meeting, the ROAD group has reached a set of
  289.    recommendations.  These recommendations are grouped in terms of a
  290.    near term and a long term approach. The short term will address the
  291.    immediate threat of Class B address exhaustion and routing table
  292.    overload.  The thinking regarding a longer-term scheme is still
  293.    preliminary.  Two approaches focus on using CLNP and address
  294.    translation, and IP encapsulation.
  295.  
  296.    The ROAD group is expected to publish a paper and make a
  297.    presentation before the San Diego IETF meeting.  One possible
  298.    approach is to spin up two Working Groups, one on each of the two
  299.    aspects of the solution.
  300.  
  301.    The IESG voiced several concerns.  The process by which the ROAD
  302.    group reached its conclusions was a closed one, and it is important
  303.    to give the ideas developed a through public hearing, and actively
  304.    solicit comments.
  305.  
  306.    To facilitate openness while moving quickly, the IESG suggested that
  307.    the ROAD group document as thoroughly as possible the options
  308.    discussed, and the specific reasons they were rejected.  By having
  309.    this document, many questions can be deferred from the meetings
  310.    themselves.
  311.  
  312. ACTION: Gross -- Take sense of the IESG discussion to the ROAD group
  313. and to Peter Ford, the other co-chair of the ROAD group, and encourage
  314. them to consider to consider the requirements for openness in the IETF
  315. process and the need for timeliness in writing the report from the ROAD
  316. group.
  317.  
  318. 5.9 IP over FDDI
  319.  
  320.    Noel Chiappa conversed with Dave Katz, the chairman of the IP over
  321.    FDDI working group.  They agreed that the specification has several
  322.    editorial changes that would be helpful, as well as a specific
  323.    technical change to the protocol to reflect current usage.
  324.  
  325.    The IESG discussed whether it was necessary to write a new document,
  326.    and after discussion, agreed that a new document should be written
  327.    before elevation to Draft Standard Status.
  328.  
  329. ACTION:  Vaudreuil, Chiappa -- Gather and forward to Dave Katz a list
  330. of changes for the IP over FDDI document.
  331.  
  332. 5.10 Network Database
  333.  
  334.    The Network Database working group appears to be moving forward in a
  335.    direction without much community support. The IESG discussed the
  336.    relative merits of the working group, but was unable to determine
  337.    the degree of community support.  There is no active liaison with
  338.    the major database vendors, and no liaison with Sqlaccess, a major
  339.    industry group defining common networking protocols for database
  340.    use.
  341.  
  342. ACTION: Russ Hobby -- Communicate with SQLAccess and get a current
  343. reading on their work and the manner in which the IETF should liaise if
  344. at all.
  345.  
  346. 7)  Working Group Actions
  347.  
  348. 7.1 Audio/Video Teleconferencing (avt)
  349.  
  350.    The IESG has not received a revised charter.  No discussion was
  351.    necessary.
  352.  
  353. 7.2 SNMP over Multi-Protocol Internet (mpsnmp)
  354.  
  355.    A new working group in the OSI Integration Area was proposed.  This
  356.    working group is tasked to complete and standardize a suite of
  357.    protocols for SNMP over FOO.  SNMP was designed to run over UDP,
  358.    however UDP is not available in all networking environments.  This
  359.    working group is considered reasonable by the SNMP community.
  360.  
  361. ACTION: Vaudreuil -- Announce the SNMP over Multi-Protocol Internet
  362. Working Group as soon a complete charter is available.
  363.  
  364. 8.0 Agenda Items Deferred
  365.  
  366.  3.4 X.400 88=>84 Downgrading           
  367.         <draft-ietf-kille-88to84downgrade>
  368.  
  369.  5.4 IANA and the Class "B" allocation strategy
  370.  5.5 Internet Draft Format Requirements "Deplorable Documents" (PG)
  371.  5.6 Email Host Requirements (Dave Crocker)
  372.  5.7 Working Group Early Warning System (Dave Crocker)
  373.  5.8 Report of the Ad Hoc meeting on DNS Security (Steve Crocker)
  374.  
  375. 6.0 Technical Evolution 
  376.  
  377.  
  378. Appendix A
  379.  
  380. Review of the Action Items
  381.  
  382. (257)  [Noel Chiappa, Greg Vaudreuil]  Assigned: Dec 12
  383.  
  384.          Contact George Clapp to document operational experience of 
  385.          the IP over SMDS protocol.                                   
  386.     
  387. Concluded.
  388.  
  389. (278)  [Steve Coya, Greg Vaudreuil]  Assigned: Feb 06
  390.  
  391.          If Huizer and Piscitello can make thedate, schedule a 1 hour
  392.          teleconference January 13th from 12PM to 1PM EST.            
  393.  
  394. Concluded.
  395.  
  396. (258)  [Dave Crocker]  Assigned: Dec 12
  397.  
  398.          Schedule a User Friendly Naming teleconference to determine 
  399.          the correct course of action for the UFN document.           
  400.  
  401. Concluded.
  402.  
  403. (245)  [Greg Vaudreuil]  Assigned: Dec 05
  404.  
  405.          Craft and send a notification to the RFC Editor to publish 
  406.          the Internet Draft "A Catalog of Available X.500 
  407.          Implementations" as an FYI RFC.                              
  408.  
  409. Concluded. The notification was sent December 13th.
  410.  
  411. (246)  [Greg Vaudreuil]  Assigned: Dec 05
  412.  
  413.          Craft, and hold a recommendation to publish the IP forwarding
  414.          MIB document as a proposed standard.                         
  415.  
  416. Concluded. The recommendation was sent 01/22/1992.
  417.  
  418. (254)  [Greg Vaudreuil]  Assigned: Dec 12
  419.  
  420.          Craft a recommendation to elevate the SIP MIB to Proposed 
  421.          Standard.                                                    
  422.  
  423. Concluded. The recommendation was send 02/10/92.
  424.  
  425. (279)  [Greg Vaudreuil]  Assigned: Feb 06
  426.  
  427.          After approval from the Internet Area Directors, craft and
  428.      send a recommendation to the IAB to publish the TOS document 
  429.      as a Proposed Standard.                                           
  430.  
  431. Concluded. the recommendation was sent 2/10/92.
  432.  
  433. (280)  [Greg Vaudreuil]  Assigned: Feb 06
  434.  
  435.          Craft and send a recommendation to the IAB recommending the 
  436.          "IP Forwarding Table MIB" be published as a Proposed Standard
  437.          RFC.  Include in the recommendation a note indicating the 
  438.          dependency on the TOS document.                              
  439.  
  440. Concluded. The recommendation was sent 01/22/1992.
  441.  
  442. (281)  [Greg Vaudreuil]  Assigned: Feb 06
  443.  
  444.          Send a message to George Clapp reminding him that the IESG 
  445.          needs information on the extent of operational deployment 
  446.          before it can move IP over SMDS to Draft Standard.           
  447.  
  448. Concluded. This is a duplicate action.
  449.  
  450. (285)  [Greg Vaudreuil]  Assigned: Feb 06
  451.  
  452.          Reschedule the RFC-Headers discussion for the February 20th 
  453.          Teleconference.                                              
  454.  
  455. Concluded. 
  456.  
  457. (287)  [Greg Vaudreuil]  Assigned: Feb 06
  458.  
  459.          Send a recommendation to the IAB that the Internet Drafts 
  460.          "Definitions of Managed Objects for Character Stream 
  461.          Devices", "Definitions of Managed Objects for 
  462.          Parallel-printer-like Hardware Devices", and "Definitions of 
  463.          Managed Objects for RS-232-like Hardware Devices" be 
  464.          published as Proposed Standard RFC's.                        
  465.  
  466. Concluded. The action was sent 2/10/92.
  467.  
  468. (292)  [Greg Vaudreuil]  Assigned: Feb 06
  469.  
  470.          Drop the TCP-Extensions document from the Active que of the 
  471.          IESG.                                                        
  472.  
  473. Concluded. No action required.
  474.  
  475. (294)  [Greg Vaudreuil]  Assigned: Feb 06
  476.  
  477.          Send a note to Steve Casner reminding him that the IESG 
  478.          cannot approve his proposed working group until an acceptable
  479.          charter has been filed with the IESG.                        
  480.  
  481. Concluded.  Casner has been reminded.
  482.  
  483. (295)  [Greg Vaudreuil]  Assigned: Feb 06
  484.  
  485.          Announce the Token Ring Monitoring Working Group to the IETF 
  486.          mailing list.                                                
  487.  
  488. Concluded.  The working group was announced 2/10/92
  489.  
  490.